nit: it would be easier to read and maintain the code if you would just call MustMarshalBinaryBare as the name suggests and handle the error instead of duplicating the logic.
(Same for the other MustXXXX methods(

Okay, I think I understand what you mean and addressed

ups, should have been "call MarshalBinaryBare". sorry

Q: types.UnpackInterfaces returns nil when the Tx does NOT implement UnpackInterfacesMessage. Do you need to handle this case to be on the safe side? Alternatively you could move UnpackInterfacesMessage into the Tx interface so that this scenario does not exist.

This question also applies to other UnpackInterfaces methods.

It makes sense to handle this because in general it will be implemented. We could update the Tx interface but I don't think we want to impose that requirement more generally right now.

Q: Same as SearchTxsResult. UnpackInterfaces

Yes, in general it will be implemented on Tx

PP: I am very happy to see errors returned. For bonus points you could add some context via errors.Wrap(err, "") to the naked errors. A single word helps already a lot when tracing down issues. Especially when there are multiple error return statements (not the case here).

Req: The CachedValue can be nil (in tests for example). It would be consistent to unpack the Any type.
Q: I am wondering about the interface cast: When m.Content is nil then nil makes sense as a result but when "CachedValue" does not implement the Content interface why returning nil instead of an error. This case should not happen with proper use of SetContent but m.Content is public so can be anything.

Is there a better approach you would suggest?

🤔 Ah, you don't have access to the unpacker without changing the method signature....
I guess you don't want to add it as a parameter but rely on the stack to initialize the object proper. As a safety net I would add the following conditions so that the method can not return anything inconsistent.

func (m *MsgSubmitProposal) GetContent() Content {
	if m.Content == nil {
		return nil
	}
	cv := m.Content.GetCachedValue()
	if cv == nil {
		panic("content was not unpacked")
	}
	content, ok := cv.(Content)
	if !ok {
		panic(fmt.Sprintf("illegal type: %T", cv))
	}
	return content
}

Same comment as with MsgSubmitProposal.GetContent

Req: content may implement UnpackInterfacesMessage that needs to be called.

UnpackAny will call those recursively

will this be deprecated in the future in favor of AminoCodec? are there any difference between the 2?

In the ADR updates in this PR I noted that we would rename this to LegacyAmino. It is more or less deprecated. The difference between the two is that Marshaler expects types that implement ProtoMarshaler (i.e. generated by protoc). So any code using Marshaler is more or less ensured to be proto compatible. This legacy Codec is pure amino.

we should this as a deprecation note on the codec.Codec godoc too.

Adding a deprecated note to the godoc

what's the difference of RegisterImplementations with RegisterInterface?

RegisterInterface also adds a public facing name to the interface. It is intended to be called the first time an interface is declared. The fact that it also takes some implementations was added as a convenience so now they're pretty similar.